Small suggestion: we can import this type directly from Scheduler's d.ts (like Appointment type is imported), instead of duplicating the type here.

Done

question: can we remove 'agenda' view from this config as it was before? Agenda view doesn't have snapping at all, and so agenda.snapToCellsMode value will never be read.

As I see in the generateViewModel function here, when generating view model for agenda, the option manager is never used. So we really don't need value for 'agenda' here

Done

I suggest to move default snapToCellsMode values to contant_view.ts.

That file already defines specific default options for each view.

If you move default values there, then we won't need to get defaultSnapToCellsMode here, because schedulerStore.getViewOption('snapToCellsMode') will be enough

I tried putting the default in constants_view.ts, but that merges into each view object, so getViewOption('snapToCellsMode') always sees a value on the view and never falls back to the root option. So defaults for snapToCellsMode can’t live in DEFAULT_VIEW_OPTIONS the same way as other view fields if we want root-level snapToCellsMode to work.

Can we add tests that check that scheduler.snapToCellsMode and scheduler.view.snapToCellsMode options actually have effect?

I mean if I have this config:

$().dxScheduler({
   snapToCellsMode: 'always',
   currentView: 'day'
})

or this config:

$().dxScheduler({
   view: [{ type: 'day', snapToCells: 'always' }]
   currentView: 'day'
})

then check that the option is applied

Added integration test which tests 3 cases for day view

1. Checks default behaviour without setting snapToCellsMode
2. Checks behaviour when root snapToCellsMode is set
3. Checks behaviour when snapToCellsMode is set via views config